Services | Systems Analysis

Determine the business needs and transform them into system requirements

Understanding business requirements is the foundation for building a solution. In Matrix, we use numerous methodologies exist for requirements elicitation, gathering, and documentation which helps us in:
1. identifying key stakeholders
2. understanding the business process
3. leading and coordinating the collection of business needs
4. documenting and organizing the business process and needs
5. analyzing the business needs and defining the business requirements
6. communicating the business requirements to an entire team for agreement

Our major techniques for collecting business needs include
1. interviews
2. brainstorming
3. prototyping
4. questionnaires
5. informal use case analysis
6. user stories, among others

Determine solutions to business software/hardware system problems

Are you curious to know the most common IT problems your business is facing? These IT problems could even be occurring in your business every day without your knowledge. One of the best ways to plan for the future of your business is to learn about the current struggles your company and employees face on a day-to-day basis. This knowledge brings the power of change and better ways to implement strategies for growth and success. We at Matrix are happy to walk you through IT issues your business might currently face. The more you know about these IT problems, the easier it will be to control and resolve them.

Analyze business processes to write system process specifications to be used

Business requirements are the critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent. A business requirements document (BRD) details the business solution for a project including the documentation of customer needs and expectations. If an initiative intends to modify existing (or introduce new) hardware/software, a new BRD should be created. Here are the main reasons to establish BRD:
• To gain agreement with stakeholders
• To provide a foundation to communicate to a technology service provider what the solution needs to do to satisfy the customer’s and business’ needs
• To provide input into the next phase for this project
• To describe what not how the customer/business needs will be met by the solution

Develop Request for Information (RFI) / Proposal (RFP) documentations

In complex projects, Matrix’s clients can benefit from multiple bidders and perspectives when seeking an integrated solution calling for a mix of technologies, vendors and potential configurations. The process starts when Matrix issues RFI to find a pool of companies who might have the potential to create the needed project. RFI will ask a standardized set of questions concerning a company’s history, capabilities, future plans, ownership, and other key details. The next step in the process is for Matrix to issue an RFP. The RFP will provide details for the different bidders and a list of questions that each bidder interested in building the project must answer.

Produce Analysis of Alternatives (AoA)

Matrix AoAs provide a framework to consistently evaluate and compare the value of different solutions for providing a needed capability to specific end users. Our typical steps in an AoA include:
• Plan: Define decision/objectives supported, identify stakeholders, define the schedule/funding/effort, establish the study team, prepare the study plan.
• Establish analysis foundation/framework: Define the analysis problem statement, context, scope, and framework for alternative comparison, including criteria to be used. Establish ground rules and assumptions that frame the analysis. Address data needs, collection, and sources prior to and during the study.
• Identify and define alternatives: Identify multiple alternatives that address the stated problem within the context and scope defined. The final set of alternatives evaluated should be the product of thorough research, vetting, and filtering.
• Assess alternatives: Evaluate each alternative against established criteria (e.g., cost, risk, effectiveness/benefit); conduct sensitivity analysis.
• Compare alternatives: Determine the relative merits of the alternatives as exposed by the analysis.
• Report results: Document results that support decision-maker/stakeholder needs.

Cost Estimation In Agile Projects

Estimation is often considered to be a black art practiced by magicians using strange rituals. It is one of the most controversial activities in Agile projects. It requires early, upfront analysis that demonstrates a high-level understanding of the program and its associated costs and benefits. Plans must provide high-level answers to questions about what they plan to deliver, how, and when; how much it will cost; and what benefits will be gained. They use this information to justify the investment, as well as planning and funding decisions. Costs and benefits for agile development can vary widely, as tasks differ in complexity, size, and scope. Our teams consider all different factors accordingly to assist in the estimation process.